Detecting and correcting radio link failures based on different usage scenarios

ABSTRACT

The disclosed subject matter provides techniques for detecting and correcting radio link failures based on the different usage scenarios. In one embodiment, a device is provided that comprises a processor, and a memory that stores executable instructions that, when executed by the processor, facilitate performance of various operations. These operations can comprise monitoring a quality of a radio link established between the device and a network device of a wireless communication network based on downlink transmissions received from the network device. These operations can further comprise determining whether the quality indicates the device and the network device are out-of-sync based on the quality being below a defined quality level, wherein the defined quality level varies based on a usage scenario associated with usage of the radio link by the device.

RELATED APPLICATION

The subject patent application is a continuation of, and claims priorityto, U.S. patent application Ser. No. 15/674,488, filed Aug. 10, 2017,and entitled “DETECTING AND CORRECTING RADIO LINK FAILURES BASED ONDIFFERENT USAGE SCENARIOS,” the entirety of which application is herebyincorporated by reference herein.

TECHNICAL FIELD

The disclosed subject matter relates to advanced wireless communicationssystems that facilitate different usage scenarios, and more particularlyto techniques for detecting and correcting radio link failures based onthe different usage scenarios.

BACKGROUND

Under the umbrella of third generation partnership project (3GPP)wireless communication technology standards, radio-access technologiesfor mobile broadband have evolved effectively to provide connectivity tobillions of subscribers and devices. Within this ecosystem, radiotechnology is evolving to cater to different usage scenarios. Forexample, 3GPP is currently defining a new standard referred to as NewRadio (NR) that caters to three families of usage scenarios defined bythe International Mobile Telecommunication system (IMT) 2020. Theseusage scenarios include enhanced Mobile Broadband (eMBB), Ultra Reliableand Low Latency Communications (URLLC), and massive Machine TypeCommunications (mMTC). Each of these usage scenarios are associated withdifferent deployment contexts and configurations, including differentcarrier frequencies, different aggregated system bandwidths, differentuser equipment (UE) distributions, different service profiles, and thelike. For example, unlike eMBB scenarios that have a relatively relaxedlatency and reliability requirements, URLLC traffic has stringentlatency (e.g., 0.5 milliseconds (ms) on the user plane for uplink anddownlink), and reliability requirements. As a result, each of thedifferent usage scenarios being developed for NR and beyond canrespectively be associated with different quality of servicerequirement. However, existing techniques for radio link monitoring(RLM) do not accommodate these different usage scenarios.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 is an illustration of an example wireless communication systemthat facilitates detecting and correcting radio link failures based ondifferent usage scenarios in accordance with various aspects andembodiments of the subject disclosure.

FIG. 2 provides a diagram demonstrating principles of radio linkmonitoring (RLM), radio link failure (RFL) detection, and radio resourcecontrol (RRC) connection re-establishment in accordance with variousaspects and embodiments of the subject disclosure.

FIG. 3 provides a diagram demonstrating principles of a random accesschannel (RACH) procedure in accordance with various aspects andembodiments of the subject disclosure.

FIG. 4 provides an example UE that facilitates detecting and correctingradio link failures based on different usage scenarios in accordancewith various aspects and embodiments of the subject disclosure.

FIG. 5 provides another example UE that facilitates detecting andcorrecting radio link failures based on different usage scenarios inaccordance with various aspects and embodiments of the subjectdisclosure.

FIG. 6 provides flow diagram describing example principles of a beamfailure recovery procedure in accordance with various aspects andembodiments of the subject disclosure.

FIG. 7 illustrates an example method for detecting radio link failuresbased on different usage scenarios in accordance with various aspectsand embodiments of the subject disclosure.

FIG. 8 illustrates another example method for detecting radio linkfailures based on different usage scenarios in accordance with variousaspects and embodiments of the subject disclosure in.

FIG. 9 illustrates an example method for detecting and correcting radiolink failures based on different usage scenarios in accordance withvarious aspects and embodiments of the subject disclosure.

FIG. 10 depicts an example schematic block diagram of a computingenvironment with which the disclosed subject matter can interact.

FIG. 11 illustrates an example block diagram of a computing systemoperable to execute the disclosed systems and methods in accordance withan embodiment.

DETAILED DESCRIPTION

The conventional RLM function at the UE monitors the downlink radio linkquality of the serving cell when in the RRC connected mode. This enablesthe UE to determine whether it is in synchronization (in-sync) or out ofsynchronization (out-of-sync) with respect to its serving cell. When anumber of consecutive out-of-sync indications are detected, the UEstarts a network-configured RLF timer. The RLF timer can be stopped if anumber of consecutive in-sync indications are reported by the UE. If thetimer expires, RLF is declared. When RLF occurs, the UE can turn off itstransmitter to avoid interference and proceeds to attempt tore-establish its RRC connection with the serving cell within a givenduration of time or within a defined delay period. If the UE fails tore-establish the RRC connection within the defined delay period, the UEcan be configured to go into an RRC idle state.

The conventional RLM, RLF and RRC do not take into account the qualityof service requirements of the different usage scenarios that are beingdeveloped and implemented for NR standards. For example, URLLC traffichas key performance metrics for latency and reliability that makes itdifficult and inappropriate to apply the same in-sync and out-of-syncdetection parameters used for other types of traffic associated withmore relaxed performance metrics (e.g., eMBB traffic).

The disclosed subject matter provides techniques for tailoring the RLM,RLF, and RRC connection re-establishment procedures at the UE based on aparticular usage scenario associated with the radio link establishedbetween the UE and the servicing cell network device (e.g., the basestation (BS), or the like). In this regard, the particular usagescenario (e.g., eMBB, URLLC, mMTC, and other possible existing andfuture usage scenarios) can correspond to a particular type of trafficand the associated quality of service requirement(s) for the particulartype of traffic. Accordingly, the RLM, RLF and RRC connectionre-establishment procedures at the UE can be tailored to be either moreor less stringent based on the quality of service requirements of thecurrent usage scenario for the current RRC connection or radio link.

For example, in various embodiments, the UE can be configured to monitorthe downlink radio link quality of the serving cell when in RRCconnected mode to determine whether the UE is in-sync or out-of-syncwith respect to its serving cell and to further determine when todeclare RLF. However, the UE's evaluation of the monitored downlinkradio link quality can be tailored based on the quality of servicerequirement of the current usage scenario. In this regard, one or moreparameters respectively used to by the UE to evaluate the radio linkquality in association with the RLM and RLF procedures can vary basedthe current usage scenario. For example, the particular number ofconsecutive out-of-sync indications detected by the UE that cause the UEto initiate the RLF timer can vary for different usage scenarios. Inanother example, the duration of the RLF timer can vary for thedifferent usage scenarios. In another example, the manner in which theUE calculates measurement representatives of the radio link quality canvary for the different usage scenarios. In another example, theparticular threshold values that are used to determine whether a UEdetermined radio link quality measurement should be considered anout-of-sync indication or an in-sync indication can vary for thedifferent usage scenarios. Accordingly, in one example implementation,in a usage scenario that involves communication of a low latency andhigh reliability type traffic (e.g., URLLC) via a radio link establishedbetween a UE and a network device, the UE can be required to maintain ahigher radio link quality level relative to a usage scenario thatinvolves a higher latency lower reliability type traffic (e.g., eMBB).In this regard, the UE can be configured to withstand a lower radio linkquality level for the low reliability type traffic relative to the radioquality link level for the high reliability type traffic beforedetermining the UE is out-of-sync with the serving cell and declaring aRLF.

Similarly, with respect to the RRC connection re-establishmentprocedure, the UE can be configured to apply different requirementsassociated with performance of the RRC connection re-establishmentprocedure based on different usage scenarios associated with a failedradio link between the UE and its server network device. For example, insome embodiments, the UE can be configured to apply differentrequirements associated with the timing of performance of one or moreaspects of the RRC connection re-establishment procedure (e.g., the RRCconnection period duration, a time period allotted for identifying theUE's serving cell, and the like). The UE can also be configured to applydifferent resource requirements for one or more aspects of the RRCconnection re-establishment procedure based on the different usagescenarios and the different quality of service requirements respectivelyassociated with the different usage scenarios.

In various embodiments, the different usage scenarios can respectivelycorrespond to different control resource set (CORESET) groups. Accordingto these embodiments, the UE can be configured to differentiate betweenRLM, RLF and RRC connection re-establishment events for the differentCORESET groups. In this regard, the parameters/requirements respectivelyassociated with the RLM/RLF and RRC connection re-establishmentprocedures can be defined differently depending on the quality ofservice requirements of the usage scenarios that respectively correspondto the different CORSET groups.

A control channel resource set (CORESET) is defined as a set of resourceelement groups (REGs) within which a UE attempts to blindly decodedownlink control information. A UE can employ one or more controlchannel resource sets (CORESETs). Each CORESET is associated with asearch space, and the search space includes aggregation level(s) and thenumber of decoding candidates for each aggregation level. Thetime/frequency resource containing at least one search space is obtainedby the UE from the master information block (MIB)/systeminformation/implicitly derived from initial access information. Thetime/frequency resource containing additional search spaces can beprovided to the UE by the network device using dedicated RRC signaling.A search space in NR is associated with a single CORESET. The searchspaces in different CORESET are defined independently.

The difference in the quality of service requirements for differentusage scenarios have prompted the need for configurable group formationsof CORESETs depending on the quality of service of the trafficenvisioned. Such configurable groupings of CORESETs are referred toherein as “CORESET groups”. A “CORESET group” refers to a plurality ofCORESETs that can be grouped together and associated with a particularquality of service requirement, set of quality of service requirements,and/or a particular a particular type of traffic/usage scenario (e.g.,eMBB, URLLC, mMTC). In this regard, a CORESET group can be defined basedon the quality of service requirements of the traffic served by thecorresponding downlink control information. Such a grouping of CORESETsis important for various applications of NR, to cater to differenttraffic needs and differentiate between control plane and user planeprocedures corresponding to different quality of service requirements.In accordance with one or more embodiments, a CORESET group is a groupof CORESETs that can be employed by a UE to decode the downlink controlinformation (DCI) corresponding to a particular usage scenario/traffictype quality of service requirement.

For example, one CORESET group can be designed to correspond to eitherURLLC traffic, where the latency and reliability requirements arestringent, or eMBB type traffic, where the latency and reliabilityrequirements are more relaxed, but higher data rates are required. Thusin various embodiments, the RLM/RLF and RRC connection re-establishmentprocedures employed by the UE in a given usage scenario can be variedbased on the CORESET group employed by the UE to decode the DCIassociated with the current usage scenario of the radio link. In thisregard, the UE can be configured to monitor the downlink radio linkquality of the serving cell when in the RRC connected mode, and makedeterminations regarding whether the UE is in-sync or out-of-sync withrespect to its serving cell, declaring RLF, and triggering RRCconnection re-establishment, based on the quality of servicerequirements that the CORESET group corresponds to.

In one or more embodiments, a device is provided (e.g., a UE) thatcomprises a processor, and a memory that stores executable instructionsthat, when executed by the processor, facilitate performance of variousoperations. These operations can comprise monitoring a quality of aradio link established between the device and a network device of awireless communication network based on downlink transmissions receivedfrom the network device. These operations can further comprisedetermining whether the quality indicates the device and the networkdevice are out-of-sync based on the quality being below a definedquality level, wherein the defined quality level varies based on a usagescenario associated with usage of the radio link by the device. Invarious implementations, the defined quality level can vary based on aquality of service requirement associated with the usage scenario,wherein the usage scenario is selected from different usage scenariosthat are respectively associated with different quality of servicerequirements. In an aspect, the different usage scenarios are selectedfrom a group comprising eMBB communications, URLLC, and mMTC. In anotheraspect, the defined quality level can vary based on a CORESET groupassociated with the usage scenario, and wherein the different usagescenarios are respectively associated with different CORESET groups.

In some implementations, the monitoring of the quality of the radio linkcomprises determining link quality measurements based on at least someof the downlink transmissions and a reference PDCCH transmissionreceived from the network device, and wherein the reference PDCCHtransmission varies based on the usage scenario. The PDCCH transmissioncan vary for different usage scenarios with respect to formatting of theDCI information or the like. In another implementation, at least some ofthe downlink transmissions comprise reference signals, wherein themonitoring the quality of the radio link comprises determining linkquality measurements based on the reference signals, and wherein thereference signals can vary based on the usage scenario.

In various additional implementations, the monitoring of the quality ofthe radio link comprises determining link quality measurements based onat least some of the downlink transmissions, wherein the determiningwhether the quality indicates the device and the network device areout-of-sync is based on detection of a defined number of consecutivelink quality measurements that are below a threshold value, and whereinthe threshold value varies based on the usage scenario. The monitoringof the quality of the radio link can also comprise determining linkquality measurements based on at least some of the downlinktransmissions, wherein the determining whether the quality indicates thedevice and the network device are out-of-sync is based on detection of adefined number of consecutive link quality measurements that are below athreshold value, and wherein the defined number of consecutive linkquality measurements varies based on the usage scenario.

In one or more embodiments, the operations can further comprise, basedon a first determination that the quality of the radio link indicatesthe device and the network device are out-of-sync, continuing themonitoring of the quality of the radio link for a defined time period(e.g., the RLF timer period), wherein the defined time period variesbased on the usage scenario. The operations can further comprisedetermining whether the quality indicates a failure of the radio link(e.g., a RLF) based on the quality remaining below the defined qualitylevel for the defined time period. According to these embodiments, theprocess of continuing the monitoring of the quality of the radio linkcomprises determining link quality measurements based on at least someof the downlink transmissions, wherein the determining whether thequality indicates the failure of the radio link based is based ondetection of a defined number of consecutive link quality measurementsthat are below a threshold value, and wherein the defined number ofconsecutive link quality measurements varies based on the usagescenario. The operations can further comprise disabling the radio linkwith the network device based on a second determination that the qualityof the radio link indicates the failure of the radio link, andperforming a connection re-establishment procedure to re-establish theradio link with the network device based on the disabling the radiolink, and wherein the connection re-establishment procedure varies basedon the usage scenario. In some implementations, the connectionre-establishment procedure can vary with respect to a timer associatedwith performance of the connection re-establishment procedure and/or aconfiguration parameter associated with resources used for theconnection re-establishment procedure.

In another embodiment, a method is provided that comprises monitoring,by a device comprising a processor, a quality of a radio linkestablished between the device and a network device of based on downlinktransmissions received from the network device. The method furthercomprises determining, by the device, whether the quality indicates thedevice and the network device are out-of-sync based on the quality beingbelow a defined quality profile, wherein the defined quality profile isvariable based on a CORESET group associated with traffic communicatedbetween the device and the network device via the radio link. In one ormore implementations, CORESET group associated with the traffic isselected from different CORESET groups based on a quality of servicerequirement associated with the traffic.

In yet another embodiment a machine-readable storage medium, comprisingexecutable instructions that, when executed by a processor of a device,facilitate performance of operations. These operations can includedeactivating a radio link established between the device and a networkdevice of a wireless communication network based on a determination thatthe radio link has failed. These operations can further includeperforming a connection re-establishment procedure to re-establish theradio link with the network device based on the terminating the radiolink, wherein the connection re-establishment procedure varies based ona control channel resource set group associated with trafficcommunicated between the device and the network device via the radiolink. In some implementations, the connection re-establishment procedurecomprises sending a L2/L3 message comprising a connection request to thenetwork device and information identifying a reason for the deactivatingthe radio link based on the control channel resource set group. Thisreason can be variable depending on the CORESET group associated withthe usage scenario. This reason can also include an inability of thedevice to successfully perform a beam failure recovery process.

The subject disclosure is now described with reference to the drawings,wherein like reference numerals are used to refer to like elementsthroughout. The following description and the annexed drawings set forthin detail certain illustrative aspects of the subject matter. However,these aspects are indicative of but a few of the various ways in whichthe principles of the subject matter can be employed. Other aspects,advantages, and novel features of the disclosed subject matter willbecome apparent from the following detailed description when consideredin conjunction with the provided drawings. In the following description,for purposes of explanation, numerous specific details are set forth inorder to provide a thorough understanding of the subject disclosure. Itmay be evident, however, that the subject disclosure may be practicedwithout these specific details. In other instances, well-knownstructures and devices are shown in block diagram form in order tofacilitate describing the subject disclosure.

FIG. 1 is an illustration of an example wireless communication system100 that facilitates detecting and correcting radio link failures basedon different usage scenarios in accordance with various aspects andembodiments of the subject disclosure. Aspects of the systems,apparatuses or processes explained in this disclosure can constitutemachine-executable component(s) embodied within machine(s), e.g.,embodied in one or more computer readable mediums (or media) associatedwith one or more machines. Such component(s), when executed by the oneor more machines, e.g., computer(s), computing device(s), virtualmachine(s), etc. can cause the machine(s) to perform the operationsdescribed.

The wireless communication system 100 can be or include various types ofdisparate networks, including but not limited to: cellular networks,femto networks, picocell networks, microcell networks, internet protocol(IP) networks Wi-Fi service networks, broadband service network,enterprise networks, cloud based networks, and the like. Wirelesscommunication system 100 can comprise one or more UEs 102, a networknode 104 and a core wireless communication network 106. It should beappreciated that a single UE 102 is depicted for exemplary purposes andthat any number of UEs can be included in wireless communication system100. The UE 102 can include a variety of different mobile and stationarydevice types that can be configured to operate perform RLM, RLF, and RRCconnection re-establishment procedures that vary based on differentusage scenarios, traffic types, and/or quality of service requirementsin accordance with various aspects and embodiments described herein. Forexample, the UE 102 can include but is not limited to: a cellular phone,a smartphone, a tablet computer, a wearable device, a virtual reality(VR) device, a heads-up display (HUD) device, and the like. In variousexemplary embodiments, the UE 102 can be configured to operate using oneor more usage scenarios that are attributed to different traffic types,quality of service requirements, and/or CORSET groups. For example, theUE 102 can be configured to communicate in accordance with eMBBcommunication standards, URLLC standards, mMTC standards, and otherpossible communication standards that tailor to different traffic typesand/or quality of service requirements. It should be appreciated thatthe eMBB communication standards, URLLC standards, and the mMTCstandards are merely exemplary and not intended to limit the concepts ofthe subject disclosure.

The UE 102 can be configured to communicate with the core wirelesscommunication network 106, and more particularly one or more networkdevices 108 of the core wireless communication network 106, using acommunication link established between the UE 102 and a network node 104of the wireless communication network. The network node 104 can beconnected to the core wireless communication network 106 (or one or morenetwork devices of the core wireless communication network 106) via oneor more backhaul links (indicated by the thick arrow line). For example,the one or more backhaul links can include wired link components, suchas but not limited to: like a T1/E1 phone line, a digital subscriberline (DSL) (e.g., either synchronous or asynchronous), an asymmetric DSL(ADSL), an optical fiber backbone, a coaxial cable, and the like. Theone or more backhaul links can also include wireless link components,such as but not limited to, line-of-sight (LOS) or non-LOS links whichcan include terrestrial air-interfaces or deep space links (e.g.,satellite communication links for navigation). The thin solid arrow linefrom the UE 102 to the network node 104 represents uplink communicationsand the thin dashed arrow line from the network node 104 to the UE 102represents downlink communications.

The non-limiting term network node (or radio network node) is usedherein to refer to any type of network node serving a UE 102 and/orconnected to other network node, network element, or another networknode from which the UE 102 can receive a radio signal. Examples ofnetwork nodes (e.g., network node 104) can include but are not limitedto: NodeB devices, base station (BS) devices, access point (AP) devices,and radio access network (RAN) devices. The network node 104 can alsoinclude multi-standard radio (MSR) radio node devices, including but notlimited to: an MSR BS, an eNode B, a network controller, a radio networkcontroller (RNC), a base station controller (BSC), a relay, a donor nodecontrolling relay, a base transceiver station (BTS), a transmissionpoint, a transmission nodes, an RRU, an RRH, nodes in distributedantenna system (DAS), and the like.

The wireless communication system 100 can employ various wirelesscommunication technologies and modulation schemes to facilitate wirelessradio communications between devices (e.g., between UEs 102 and betweenUEs 102 and the network node 104, between the network node 104 and oneor more network devices 108, etc.). For example, the UEs 102 can beconfigured to communicate with the network node 104, and vice versausing various wireless communication technologies, including but notlimited to: Universal Mobile Telecommunications System (UMTS)technologies, LTE technologies, advanced LTE technologies (includingvoice over LTE or VoLTE), narrowband IoT (NB-IoT), Code DivisionMultiple Access (CDMA) technologies, Time Division Multiple Access(TDMA) technologies, Orthogonal Frequency Division Multiplexing (OFDN)technologies, Filter Bank Multicarrier (FBMC) technologies, WirelessFidelity (Wi-Fi) technologies, Worldwide Interoperability for MicrowaveAccess (WiMAX) technologies, General Packet Radio Service (GPRS)technologies, Enhanced GPRS, technologies, Third Generation PartnershipProject (3GPP) technologies, Fourth Generation Partnership Project(4GPP) technologies, Fifth Generation Partnership Project (5GPP)technologies, Ultra Mobile Broadband (UMB) technologies, High SpeedPacket Access (HSPA) technologies, Evolved High Speed Packet Access(HSPA+), High-Speed Downlink Packet Access (HSDPA) technologies,High-Speed Uplink Packet Access (HSUPA) technologies, ZIGBEE®technologies, or another IEEE 802.XX technology. Additionally,substantially all aspects disclosed herein can be exploited in legacytelecommunication technologies.

The core wireless communication network 106 can include various networkdevices 108 that facilitate providing wireless communication services tothe UEs 102 via the network node 104 and/or various additional networkdevices (not shown). For example, the one or more network devices 108 ofthe core wireless communication network 106 can include but are notlimited to: mobile switching center (MSCs) devices, a home locationregister (HLR) device, a visitor location register (VLR) device,authentication center (AUC) devices, provisioning servers, billingservers, operation and support system (OSS) devices, short messageservice center (SMSC) devices, and many other elements. In someimplementations, the one or more network devices 108 includes a mobilitymanagement entity (MME) device. For example, the system architectureevolution (SAE) is the core network architecture of 3GPP's LTE wirelesscommunication standard. In accordance with SAE, the MME is the keycontrol-node for the LTE access-network. The MME is involved in thebearer activation/deactivation process and is also responsible forchoosing the serving gateway (SGW) for a UE at the initial attach, theTAU procedure, and at time of intra-LTE handover involving core network(CN) node relocation. The MME is also responsible for idle mode UEpaging and tagging procedure including retransmissions.

In accordance with various aspects and embodiments described herein,wireless communication system 100 can be configured to facilitatedetecting and correcting radio link failures based on different usagescenarios in association with a wireless radio link established betweenthe UE 102 and the network node 104. In particular, the UE 102 and thenetwork node 104 of wireless communication system 100 can be configuredto employ RLM, RLF and RRC connection re-establishment procedures thatare specifically tailored to the different quality of servicerequirements associated with the different usage scenarios. Thesedifferent usage scenarios can correspond to for example, a differenttraffic types and/or different CORESET groups.

FIG. 2 provides a diagram 200 demonstrating example principles of RLM,RLF detection, and RRC connection re-establishment in accordance withvarious aspects and embodiments of the subject disclosure. In accordancewith various embodiments, when a UE (e.g., UE 102) has established aradio link with a network device (e.g., network node 104) or isotherwise in the RRC connected mode, the UE can be configured to performRLM to monitor the downlink radio link quality. The RLM proceduregenerally involves two phases or periods, respectively represented indiagram 200 as the out-of-sync detection period 201 and the RLF timerperiod 202. If RLF is declared upon the expiration of the RLF timerperiod 202, the UE can be configured to initiate the RRC connectionre-establishment procedure which can occur over another defined periodrepresented in diagram 200 as the RRC re-establishment period 203.

With reference to FIGS. 1 and 2, in accordance with the RLM procedure,the UE 102 can be configured to monitor the downlink radio link qualityof the radio link established between the UE 102 and the network node104 based on downlink transmissions received from the network node 104.In this regard, the UE can be configured to determine, (eitherregularly, continuously, at defined time points, based on reception ofparticular downlink transmissions or groups of downlink transmissions,based on defined trigger events, etc.), radio link quality measurementsrepresentative of the UEs estimate of the downlink radio link qualitybased on one or more of the downlink transmissions. For example, in someembodiments, the downlink transmissions monitored can include referencesignals transmitted by the network node 104 and the UE can be configuredto determine the radio link quality measurements based on one or more ofthe reference signals. In some implementations, the downlink signalsmonitored/evaluated by the UE to determined the downlink radio qualitylink measurements can include other types of signals (e.g., actualphysical downlink control channel (PDCCH) transmissions) transmitted tothe UE by the network node 104.

In various implementations, the radio link quality measurements areexpressed in terms of block error rate (BLER) of a hypothetical orreference PDCCH transmission from the network node 104. In particular,in accordance with various NR standards, the network node 104 providesthe UE downlink control information via the PDCCH to convey schedulingdecisions and various other types of control information (e.g.,information regarding the CORESET groups to be employed by the UE).Accordingly, correct reception and decoding by the UE of the PDCCHtransmissions is critical to the correct operation of the network. Thusin some implementations, the criteria for determining measures of thedownlink quality that indicate out-of-sync and in-sync conditions can bebased on whether the UE can reliably decode the PDCCH or not.

A number of different formats can be used for the transmission of theDCI on the PDCCH in order to adapt to variations in the quality of thetransmission link between the network node 104 and the UE 102. Thesedifferent formats correspond to different levels of error correctionredundancy and hence have different signal to noise ratio (SNR)requirements. In various implementations, an indication that the UE 102is out-of-sync with the network node 104 can be based on failure of theUE to reliably receive a first hypothetical PDCCH transmitted with afirst format using a high level of redundancy. On the other hand, anindication that the UE is in-sync with the network node 104 can be basedon an estimate that the UE can correctly receive DCI transmitted on thePDCCH with a second format using a low level of error correctionredundancy. Accordingly, in some implementations, the BLER measurementsdetermined by the UE 102 that are used to determine if the UE is in-syncand out-of-sync are based on received downlink transmissions from thenetwork node (e.g., received reference signals) in view of these twohypothetical or reference PDCCH formats. For example, in someimplementations, the UE 102 can determine BLER measurementsrepresentative of the estimated downlink channel quality based on thetone quality and/or signal strength of received reference signals inview of the parameters defined for the hypothetical/reference PDCCHs.However, in one or more alternative implementations, the UE 102 candetermine the BLER measurements based on actual PDCCH transmissionsreceived from the network node 104.

With reference to diagram 200, in various embodiments the out-of-syncdetection period 201 begins when the UE 102 first determines one or morelink quality measurements that indicate the UE is out-of-sync with thenetwork node 104 with respect to a defined threshold link quality value.This initial out-of-sync detection is identified in diagram 200 atmarker (1). In this regard, the UE can determine that is out-of-syncwhen a radio link quality measurement is worse than a threshold value,referred to as Qout. The UE can also determine that it is in-sync when aradio link quality measurement is better than another threshold value,referred to as Qin. The Qout value can thus reflect a link quality levelat which the downlink radio link cannot be reliably received and the Qinvalue can reflect a link quality level at which the downlink radio linkquality can be significantly more reliably received than at Qout. Invarious embodiments, these thresholds can be expressed in terms of theBLER of the hypothetical/reference PDCCH transmissions discussed above.For instance, in one example, the Qout value can correspond to a 10%BLER of a first hypothetical/reference PDCCH transmission taking intoaccount the physical control format indicator channel (PCFICH) errors.The Qin value can correspond to a 2% BLER of secondhypothetical/reference PDCCH transmission taking into account the PCFICHerrors. Accordingly, in one or more embodiments, the UE can detect anout-of-sync indication based on measured BLER estimates that are greaterthan (or equal to) Qout. Likewise, the UE can detect an in-syncindication based on measured BLER estimates that are less than (or equalto) Qin.

After the UE detects an initial out-of-sync detection (e.g., as shown bymarker (1) in diagram 200), the UE can be configured to continue tomonitor the downlink channel quality by calculating subsequent channellink quality measurements (e.g., BLERs). If the UE detects a definednumber (N1) of consecutive out-of-sync detections, the UE can then startthe RLF timer, indicated in diagram 200 as marker (2). The RLF timer hasa predefined duration (e.g., 20 ms, 20 frames, etc.) which controls theduration of the RLF timer period 202. The RLF timer can be stopped if adefined number of consecutive in-sync indications are measured by theUE. In the embodiment shown, a determination that the downlink radiolink quality is above a certain threshold can be based on detection ofanother defined number (N2) of in-sync detections, shown in diagram 200as marker (3). In this regard, if the UE detects a defined number (N2)of in-sync indications within the RLF timer period, the UE can stop theRLF timer, and restart the RLM cycle. However, if the downlink radiolink quality remains below Qout for the duration of the RLF timer period202, RLF is declared. According to this embodiment, upon expiration ofthe RLF timer period 202 without detecting another defined number onin-sync indications, the UE can declare RLF, as shown at marker (4).

When RLF occurs, the UE 102 can be configured to turn off itstransmitter to avoid interference. In this regard, the UE 102 caneffectively disable, deactivate or otherwise or otherwise terminate thecurrent radio link. The UE 102 can further be configured to proceed toattempt to re-establish its RRC connection with the network node 104within a given duration of time or delay period. For example, in theembodiment shown, the RRC re-establishment period 203 corresponds to thedefined time delay within which the UE is required to provide an RRCreconnection request, shown in diagram at marker (5). If the UE fails toprovide the RRC reconnection request and re-establish the RRC connectionwithin the RRC re-establishment period 203, the UE can go into an RRCidle state.

The conventional RLM, RLF and RRC connection re-establishment proceduresfor LTE do not take into account the quality of service requirements ofthe different usage scenarios that are being developed and implementedfor NR standards. For example, URLLC traffic has key performance metricsfor latency and reliability that makes it difficult and inappropriate toapply the same in-sync and out-of-sync detection parameters used forother types of traffic associated with more relaxed performance metrics(e.g., eMBB traffic). In accordance with various embodiments, the UE 102can be configured to tailor one or more aspects of the RLM, RLF, and RRCconnection re-establishment procedures described with reference todiagram 200 based on the quality of service requirements associated witha particular usage scenario of the radio link established between the UE102 and the network node 104. For example, as described supra, thedifferent usage scenarios can respectively correspond to or otherwise beassociated with different types of traffic (e.g., eMBB, URLLC, mMTC,etc.), different quality of service requirements, and/or differentCORESET groups.

In various embodiments, the RLM, RLF and RRC connection re-establishmentprocedures can be tailored to different usage scenarios/traffic typeand/or CORSET groups with respect to the parameters and/or proceduralrequirements respectively applied by the UE 102 to evaluate the radiolink quality in association with the RLM and RLF procedures. In thisregard one or more parameters and/or procedural requirements (e.g., thethreshold values for Qout and Qin, N1, N2, the RLF timer, etc.) definedfor the RLM and RLF procedures can vary based the current usagescenario/traffic type and/or CORESET group. In addition, one orparameters and/or procedural requirements associated with the RRCconnection re-establishment procedure (e.g., the connectionre-establishment duration timer) can be tailored to account fordifferent usage scenarios.

The UE 102 can be provided with information defining the differentparameters and/or procedural requirements associated with performingRLM, RLF and RRC connection re-establishment procedures in differentusage scenarios. The UE can further apply the applicable parametersand/or procedural requirements based on the current usage scenario,traffic type, quality of service requirement, and/or CORESET groupassociated with a radio link between the UE 102 and the network node104. The information defining the different parameters and/or proceduralrequirements associated with performing RLM, RLF and RRC connectionre-establishment procedures by the UE in different usage scenarios isgenerally referred to herein as RLM/RLF procedure information. Themanner in which the UE acquires the RLM/RLF procedure information canvary. In some implementations, the RLM/RLF procedure information can bepredetermined by the network and stored in local memory of the UE. Inother implementations, the network can determine the RLM/RLF informationbased on current network conditions and provide the RLM/RLF informationto the UE via the system information or the PDCCH.

In one or more embodiments, with respect to RLM for different usagescenarios/traffic types and/or CORESET groups, the RLM/RLF procedureinformation can define different hypothetical/reference PDCCHtransmissions for applying by the UE in association with determiningBLER measurements that reflect a downlink radio link qualitymeasurement. For example, as described above, in some implementations,the in-sync and out-of-sync threshold values (e.g., Qin and Qout,respectively) used in RLM are expressed in terms of BLER values that arerespectively based on two hypothetical/reference PDCCH transmissionsfrom a serving cell. These hypothetical/reference PDCCH transmissionscan be defined differently to account for different usagescenarios/traffic types and/or CORSET groups. In one example, thedifference in the hypothetical/reference PDCCH transmissions cancorrespond to different DCI format definitions for comparison with thein-sync and out-of-sync threshold values. In this regard, the monitoringof the quality of the radio link can comprise determining link qualitymeasurements based on a reference PDCCH transmission, and wherein aformat of the DCI used in transmission of the reference PDCCHtransmission varies based on the usage scenario. According to thisexample, the different hypothetical/reference PDCCH transmissionsassociated with the different usage scenarios/traffic types and/orCORESET groups can vary with respect aggregation levels, resourceelements (RE)s, energy ratios, and the like. In another implementation,the RLM/RLF procedure information can define different reference signalsfor use by the UE when calculating the BLER measurements. For example,the network node 104 can send reference signals associated withdifferent characteristics. For example, the reference signal densitiescan vary or the manner in which the reference signals occupy thetime/frequency resources can vary. Thus the particular reference signalsevaluated by the UE to determine radio link quality measurements and/orthe manner in which the reference signals are formatted can vary basedon the usage scenario. For example, the different hypothetical/referencePDCCH transmissions per usage scenario/traffic type and/or CORESET groupcan correspond to different reference signal types, different referencesignals combinations, and the like used for the comparison with thein-sync and out-of-sync thresholds.

In another embodiment, with respect to RLM for different usagescenarios/traffic types and/or CORESET groups, the RLM/RLF procedureinformation can define different in-sync and out-of-sync thresholdvalues for applying by the UE when evaluating the radio qualitymeasurements determined by the UE 102. For instance, the in-sync andout-of-sync thresholds can correspond to different BLER targetsdepending on the quality of service requirements of the different usagescenarios/traffic types and/or CORESET groups. For example, the BLERtargets for URLLC traffic can be more stringent than BLER requirementsfor eMBB traffic. According to this example, the BLER value thresholdvalue (Qout) for determining an out-of-sync measurement for the URLLCtraffic can be lower (e.g., 5%) relative to the BLER threshold value(Qout) for determining an out-of-sync measurement for the eMMB traffic(e.g., 12%).

In another embodiment, with respect to RLM for different usagescenarios/traffic types and/or CORESET groups, the RLM/RLF procedureinformation can define different timers or delay thresholds fordeclaring that the UE is out-of-sync, and subsequently declaring RLF.These timers can correspond to the out-of-sync detection period 201 andthe RLF timer period 202. For example, in some implementations, thenumber of consecutive out-of-sync detections (N1, wherein N1 can be oneor more) to start the RLF timer can be different for different usagescenarios/traffic types and/or CORESET groups. Moreover, the RLF timerduration (i.e., the RLF timer period 202) can be tailored to thedifferent usage scenarios/traffic types and/or CORESET groups. Inaddition, the number of consecutive out-of-sync detections (N2) that canoccur in the RLF timer period 202 before declaring a RLF can also varybased on the different usage scenarios/traffic types and/or CORESETgroups. Further, the number of consecutive successful in-sync detectionsthat can occur during the RLF timer period that can cause the UE toabandon the RLF timer period 202, maintain the radio link, and restartthe RLM procedure can also vary based on the different usagescenarios/traffic types and/or CORESET groups.

Furthermore, the RLM/RLF procedure information can define differentparameters/requirements associated with the RRC connectionre-establishment procedure based on the different usagescenarios/traffic types and/or CORESET groups. For example, in someimplementations, in order for the UE 102 to successfully re-establishthe RRC connection, the UE can be required to complete one or more RRCconnection re-establishment tasks within a defined time period or timedelay. For example, in the embodiment shown in FIG. 2, the UE can berequired to provide the RRC reconnection request within a defined RRCre-establishment period 203. In another implementation, the RRCconnection re-establishment procedure can include a defined time delayfor acquiring the uplink grant for sending the RRC reconnection requestmessage, a defined time delay to search for the target cell, a definedtime delay to read the target cell system information, a defined timedelay to complete a random access procedure, and the like. Accordingly,one or more of these various defined time delays or time periods can bealso be tailored based on the quality of service requirement(s)associated with the different usage scenarios/traffic types and/orCORESET groups. For example, the time required for performance of arandom access procedure can be configured to be lower for latencyconstrained systems as opposed to usage scenarios that are less latencyconstrained.

The random access procedure, also referred to as the random accesschannel (RACH) procedure, is a specific RRC connection procedure that isused by UEs in LTE and NR communication systems to recover from a RLF.Thus in various embodiments, the RRC connection re-establishmentprocedure can be or involve the RACH procedure.

FIG. 3 provides a diagram 300 demonstrating example principles of theLTE RACH procedure in accordance with various aspects and embodiments ofthe subject disclosure. Repetitive description of like elements employedin respective embodiments is omitted for sake of brevity.

As shown in diagram 300, the RACH procedure consists of four steps orRACH events. These RACH events include the transmission of the randomaccess preamble by the UE to the network node at 301; the transmissionof the random access response (RAR) message by the network node 104 tothe UE at 302, the transmission of the L2/L3 message (which comprisesRRC connection request) by the UE 102 to the network node 104 at 303;and the transmission of the contention resolution message by the networknode 104 to the UE 102 at 304. In various embodiments, one or more ofthe RACH events/steps can be configured differently for the differentusage scenarios/traffic types and/or CORESET groups. For example, insome implementations, the time/frequency resources used for RACHpreamble transmission can be tailored to each particular usagescenario/traffic type and/or CORSET group. In this regard, the manner inthe time/frequency resources occupied by the preamble and/or the mannerin which the RACH resources are multiplexed in time or frequency can betailored to account for a particular usage scenario/traffic type and/orCORSET group (and the associated quality of service requirement(s)). Inanother embodiment of the configuration of RACH procedure, the RARwindow can be configured for a particular usage scenario/traffic typeand/or CORSET group. For example, the UE expects to receive the RARwithin a defined time window, of which the start and end are configuredby the network and broadcast as part of the cell-specific systeminformation. This RAR window can be configured per each usagescenario/traffic type and/or CORESET group, such that the RAR window isshorter for latency constrained usage scenarios.

FIG. 4 provides an example UE 400 that facilitates detecting andcorrecting radio link failures based on different usage scenarios inaccordance with various aspects and embodiments of the subjectdisclosure in accordance with various aspects and embodiments of thesubject disclosure. In various embodiments, the UE 102 of wirelesscommunication system 100 can be or include UE 400, or vice versa.Repetitive description of like elements employed in respectiveembodiments is omitted for sake of brevity.

In the embodiment shown, UE 400 can include communication component 402,link quality monitoring component 406, link quality evaluation component408, and reconnection component 412. The UE 400 can also include powersource 414, a processor 416 and a memory 418. The power source 414 caninclude, but is not limited to, a battery, a capacitor, a charge pump, amechanically derived power source (e.g., microelectromechanical systems(MEMs) device), or an induction component. The memory 418 can beconfigured to store computer executable components and instructions(e.g., one or more software components of the communication component402, such as the usage scenario identification component 404, the linkquality monitoring component 406, the link quality evaluation component408 and the reconnection component 412. The processor 416 can beconfigured to facilitate operation of the computer executable componentsand instructions by the UE 400. In some implementations, the memory 418can also store the RLM/RLF procedure information 420. The UE 400 canalso include a device bus 410 that couples the various components of theUE, including but not limited to the communication component 402, thelink quality monitoring component 406, the link quality evaluationcomponent 408, the reconnection component 412, the power source 414, theprocessor 416 and the memory 418. Examples of said processor 416, andmemory 418, as well as other suitable computer or computing-basedelements that can be employed by the UE 400, can be found with referenceto FIG. 11.

With reference to FIGS. 1, 2, 3 and 4, the communication component 402can be configured to facilitate various wired and wirelesscommunications between the UE and other devices, including at least thenetwork node 104. The types of communications can include a plurality ofdifferent types in accordance with various wireless communicationtechnologies. In accordance with one or more embodiment so the disclosessubject matter, the communication component 402 can facilitate at leastwireless communications associated with different NR usage scenarios(e.g., eMMB, URLLC, and mMTC for example). The communication component402 can include software, hardware, or a combination of software andhardware that is configured to facilitate such wired and/or wirelesscommunications. For example, the communication component 402 can be orinclude hardware (e.g., a central processing unit (CPU), one or moretransmitters, one or more receivers, one or more transceivers, one ormore decoders), software (e.g., a set of threads, a set of processes,software in execution) or a combination of hardware and software thatfacilitates one or more of the various types of wireless communicationsdescribed herein.

In the embodiment shown, the communication component 402 can include theusage scenario identification component 404 to facilitate determiningthe particular usage scenario associated with a current or intendedusage of a radio link established between the UE and the network node104. In this regard, the usage scenario identification component 404 canbe configured to determine one or more of: the particular usage scenarioassociated with a current or intended usage of the radio link, a qualityof service requirement associated with the usage scenario, a type oftraffic associated with the usage scenario, and a CORESET groupassociated with the usage scenario. Based on the determined usagescenario, quality of service requirement, traffic type and/or CORESETgroup, the UE can determine which particular RLM, RLF and/or RRCconnection re-establishment parameters and requirements to apply asdefined by the RLM/RLF procedure information 420.

For example, with respect to the out-of-sync detection period 201, theRLM/RLF procedure information can 420 include but is not limited to, foreach (or in some cases one or more) different usage scenario/traffictype and/or CORSET group: the particular characteristics of thehypothetical/reference PDCCH transmissions to be applied to determinethe BLER values corresponding to link quality measurements, theparticular reference signal characteristics/combinations used todetermine the BLER values, the specific Qout and Qin values, and thenumber (e.g., N1) of consecutive out-of-sync indications applied toinitiate the RLF timer.

With respect to the RLF timer period 202, the RLM/RLF procedureinformation 420 can include but is not limited to, for each (or in somecases one or more) different usage scenario/traffic type and/or CORSETgroup: the particular characteristics of the hypothetical/referencePDCCH transmissions to be applied to determine the BLER valuescorresponding to link quality measurements (which can be the same ordifferent relative to those associated with the out-of-sync detectionperiod 201), the particular reference signalcharacteristics/combinations used to determine the BLER values (whichcan be the same or different relative to those associated with theout-of-sync detection period 201), and the specific Qout and Qin values(which can be the same or different relative to those associated withthe out-of-sync detection period 201). In addition, with respect to theRLF timer period, the RLM/RLF procedure information 420 can include butis not limited to, for each (or in some cases one or more) differentusage scenario/traffic type and/or CORSET group: the duration of the RLFtimer or RLF timer period, and possible number(N2) of consecutivein-sync indications required to Stop the RLF timer, and return to theRLM procedure.

With respect to the RRC re-establishment period 203, the RLM/RLFprocedure information can 420 include bust is not limited to, for each(or in some cases one or more) different usage scenario/traffic typeand/or CORESET group: time delays or time periods defined for one ormore RACH events (e.g., the time period for receiving the RAR, the timeperiod for providing the RRC connection request, and the like), as wellas time/frequency resources used for one or more of the RACH events(e.g., the preamble transmission), and multiplexing requirements formultiple RACH resources in time or frequency.

The link quality monitoring component 406 can be configured to performthe various aspects of RLM discussed herein in accordance with theapplicable RLM parameters that correspond to the current usagescenario/traffic type, CORSET group and/or associated quality of servicerequirements as determined by the usage scenario identificationcomponent 404. For example, the link quality monitoring component 406can be configured to monitor the quality of a radio link establishedbetween the UE 400 and the network node 104 based on downlinktransmissions received from the network device. In this regard, the linkquality monitoring component 406 can be configured to determine linkquality measurements (e.g., BLER values) based on at least some of thedownlink transmissions and a hypothetical/reference PDCCH transmissionassociated with the current usage scenario (e.g., wherein thehypothetical/reference PDCCH transmission varies based on the usagescenario). In some implementations, the hypothetical/reference PDCCHtransmission can vary with respect to the CSI formatting. In anotherimplementation, the link quality monitoring component 406 can determinethe link quality measurements based on reference signals, wherein thereference signals vary based on the usage scenario (e.g., with respectto combinations thereof, formatting, density, etc.).

The link quality evaluation component 408 can be configured to evaluatethe downlink radio link quality based on the measurements monitored bythe link quality monitoring component 406 to determine if the UE and thenetwork node are sufficiently out-of-sync to initiate the RLF timer andto declare RLF in accordance with the mechanisms discussed herein. Thedeterminations/evaluations made by the link quality evaluation component408 can also be tailored to reflect the applicable RLM parameters thatcorrespond to the current usage scenario/traffic type, CORESET groupand/or associated quality of service requirements as determined by theusage scenario identification component 404. For example, the linkquality monitoring component 408 can be configured to determine whetherthe monitored link quality indicates the device and the network deviceare out of synchronization based on the link quality being below adefined quality level, wherein the defined quality level varies based ona usage scenario associated with usage of the radio link by the device.In this regard, the defined quality level and the measured quality ofradio link can reflect one or more RLM/RLF parameters that are tailoredto the usage scenario, including but not limited to: the particularcharacteristics of the hypothetical/reference PDCCH transmissionsapplied to determine the BLER values corresponding to link qualitymeasurements, the particular reference signalcharacteristics/combinations used to determine the BLER values, thespecific Qout and Qin values, and the number of consecutive out-of-syncindications applied to initiate the RLF timer. Based on a firstdetermination that the quality of the radio link indicates the UE 400and the network node 104 are out-of-sync, the link quality evaluationcomponent 408 can further determine, based on continued monitoring ofthe downlink radio link quality during the RLF timer period 202, thelink quality indicates a failure of the radio link based on the qualityremaining below the defined quality level for the defined time period.Again, this determination can be based on specific parameters associatedwith the current usage scenario as defined in the RLM/RLF procedureinformation 420.

Further, the reconnection component 412 can be configured to controlperformance of the RRC connection re-establishment procedure by thecommunication component 402 in accordance with the various mechanismsdiscussed herein which can be specifically defined in the RLM/RLFprocedure information 420 for the different usage scenarios. Forexample, the reconnection component 412 can direct the communicationcomponent 402 to apply a particular timer for the RRC reconnectionperiod that is configured for the CORESET group associated with usage ofthe failed radio link. In another example, the reconnection component412 can direct the communication component 402 to apply a particulartime/frequency resource allocation and/or multiplexing for the RACHpreamble that is configured specifically for the traffic type associatedwith usage of the failed radio link.

FIG. 5 provides another example UE 500 that facilitates detecting andcorrecting radio link failures based on different usage scenarios inaccordance with various aspects and embodiments of the subjectdisclosure in accordance with various aspects and embodiments of thesubject disclosure. UE 500 can include same or similar features andfunctionalities as UE 400 with the addition of the beam failure recoverycomponent 502. Repetitive description of like elements employed inrespective embodiments is omitted for sake of brevity.

The RLM procedure and triggering of RLF is linked to a physical layerprocedure called beam failure recovery. In accordance with various NRstandards, the network will use a certain beam to talk to another beamof the UE 500. These respective beams establish what is referred to as abeam pair link (BPL). The UE 500 can be configured with one or multiplesets of BPLs. Each set of BPL is associated with one reference signal(RS) resource, and can correspond to one CORESET group, traffic type,usage scenario, etc. In certain deployment scenarios, one or more of theBPLs can become blocked due a blockage effect in the channel, especiallyat higher frequencies. When a BPL is blocked, the UE 500 cannotcommunicate information with the network node via the BPL. Accordingly,when all of the UEs BPLs are blocked, the radio link essentially fails.In order to recover from a BPL blockage, the UE uses what is known as abeam failure recovery process to find another link or otherwise performa series of steps to recover the blocked PBL. If it cannot recover, andall of the UEs BPLs are blocked, the UE declares a RLF. The UE 500 canthen be configured to initiate the RRC connection re-establishmentprocedure according to the various aspects and embodiments describedherein (e.g., wherein one or more aspects of the RACH procedure aretailored to a particular usage scenario/traffic type and/or CORESETgroup).

FIG. 6 provides a flow diagram 600 describing example principles of abeam failure recovery procedure in accordance with various aspects andembodiments of the subject disclosure. The basic working procedure is asfollows. At 602, the UE identifies one or more beam failures based onthe configured RS resources using the one or more beams. For example,beam failure recovery can run on a plurality of beams and the UE canperform the beam failure recovery process on each of the beams. At 604,the UE identifies some alternative BPLs (including transmitter (Tx) andreceiver (Rx) beams) that the UE can use to communicate with thenetwork. At 606, the UE transmits uplink signaling to indicate the beamfailure as well as the alternative beams. In some implementations, if at608 the UE is unable to successfully transmit the uplink signalinginformation within the threshold number of attempts, then the beamfailure recovery process processed to 616, wherein the UE considers thebeam failure recovery process unsuccessful. The UE can then disable thelink and initiate the reconnection procedure at 618.

However, if at 608, the uplink signaling is successfully transmit to thenetwork node within a defined number or threshold number of attempts,the UE can proceed to 610. At 610, the UE switches the PDCCH receiverbeam according to the alternative beams to monitor the PDCCH forconfirmation. If at 612, the UE determines the configuration isreceived, the UE declares the beam failure recovery procedure successfulat 614 and maintains the integrity of the radio link between the UE andthe network node. However if at 612, the confirmation is not received,then at 616, the UE declares the beam failure recovery procedureunsuccessful. As a result, at 618, the UE declares RLF, disables theradio link, and initiates the RRC connection re-establishment procedure.Also, at 608, if the UE unsuccessfully attempts to transmit uplinksignaling to indicate the beam failure as well as the alternative beamsa certain configurable number of times, the UE declares the beam failurerecovery procedure unsuccessful. Although FIG. 6 demonstrates somereasons why beam pair recovery may be unsuccessful, it should beappreciated that these are merely exemplary and that there are multiplereasons why the beam recovery procedure fails and hence RLF istriggered.

With reference to FIGS. 5 and 6 in various embodiments, the beam failurerecovery component 502 can be configured to facilitate detecting BPLblockages and performance of the beam failure recovery procedure by theUE 500. For example, the beam failure recovery component 502 can declareRLF in response to unsuccessful beam failure recovery procedures whenthe UE 500 cannot communicate with the network via its respective BBLs.The beam failure recovery component 502 can further direct thecommunication component 402 to initiate and perform the RRC connectionre-establishment procedure, (particular the RACH procedure in someimplementations), in accordance with the parameters and protocolsassociated with the current usage scenario/traffic type and/or CORESETgroup.

Furthermore, in some embodiments, in association with performance of theRRC connection re-establishment procedure, the usage scenarioidentification component 404 can direct the communication component 402to differentiate between the different reasons to why a RLF was declaredwith respect based on the current usage scenario/traffic type and/orCORESET group. In this regard, in association with performance of theRRC connection re-establishment procedure, the communication component402 can provide the network node 104 with information identifying thereason for the RLF. This reason can include for example, a determinationthe UE and the network node 104 are out-of-sync depending on the currentusage scenario. This reason can also include a determination that a beamfailure recovery procedure was unsuccessful in associated with aparticular CORESET group associated with the blocked BPL(s). In someimplementations, the information provided by the communication component402 to the network node indicating the reason for the RLF can alsoidentify the current usage scenario/traffic link and/or CORESET groupconsidered by the UE when determining the RLF. In some embodiments,information regarding the reason for the RLF failure and/or theassociated usage scenario/traffic link and/or CORESET group can beprovided by the communication component 402 to the network node with theRRC connection request message (e.g., message L2/L3 of the RACHprocedure) during the RRC connection re-establishment.

In one or more embodiments, based on the indicated RLF reason, which cancorrespond to the usage scenario, the network node response can beconfigurable. In one example, the network node 104 can determine awhether to perform a fast re-activation of the RRC connection as opposedto a standard re-activation. In another example, the network node candetermine to whether to reconfigure or reactive the RRC connection inassociation with re-establishment of the radio link based on theparticular reason for the RLF and the associated usage scenario/traffictype and/or CORESET group. In this regard, the determination toreconfigure verses reactivate the radio link can be based on the usagescenario. In one example, based on information included in the RRCconnection request indicating a latency constrained usage scenarios wasattributed to the RLF determination, the network node 104 can beconfigured to perform a fast re-activation of the radio link (as opposedto a standard slower reactivation of the radio link) to overcome thedelays corresponding to the RRC connection re-establishment.

In view of the example system(s) described above, example method(s) thatcan be implemented in accordance with the disclosed subject matter canbe better appreciated with reference to flowcharts in FIGS. 7-9. Forpurposes of simplicity of explanation, example methods disclosed hereinare presented and described as a series of acts; however, it is to beunderstood and appreciated that the claimed subject matter is notlimited by the order of acts, as some acts may occur in different ordersand/or concurrently with other acts from that shown and describedherein. For example, one or more example methods disclosed herein couldalternatively be represented as a series of interrelated states orevents, such as in a state diagram. Moreover, interaction diagram(s) mayrepresent methods in accordance with the disclosed subject matter whendisparate entities enact disparate portions of the methods. Furthermore,not all illustrated acts may be required to implement a describedexample method in accordance with the subject specification. Furtheryet, two or more of the disclosed example methods can be implemented incombination with each other, to accomplish one or more aspects hereindescribed. It should be further appreciated that the example methodsdisclosed throughout the subject specification are capable of beingstored on an article of manufacture (e.g., a computer-readable medium)to allow transporting and transferring such methods to computers forexecution, and thus implementation, by a processor or for storage in amemory.

FIG. 7 illustrates an example method 700 for detecting radio linkfailures based on different usage scenarios in accordance with variousaspects and embodiments of the subject disclosure. Repetitivedescription of like elements employed in respective embodiments isomitted for sake of brevity.

At 702, a device comprising a processor (e.g., a UE 102, UE 400, UE 500or the like), monitors (e.g., using the link quality monitoringcomponent 406) a quality of a radio link established between the deviceand a network device (e.g., network node 104) of a wirelesscommunication network based on downlink transmissions received from thenetwork device. At 704, the device determines (e.g., using the linkquality evaluation component 408) whether the quality indicates thedevice and the network device are out of synchronization based on thequality being below a defined quality level, wherein the defined qualitylevel varies based on a usage scenario associated with usage of theradio link by the device. In this regard, the defined quality level andthe measured quality of radio link can reflect one or more RLM/RLFparameters that are tailored to the usage scenario, including but notlimited to: the particular characteristics of the hypothetical/referencePDCCH transmissions applied to determine the BLER values correspondingto link quality measurements, the particular reference signalcharacteristics/combinations used to determine the BLER values, thespecific Qout and Qin values, and the number of consecutive out-of-syncindications applied to initiate the RLF timer.

FIG. 8 illustrates another example method 800 for detecting radio linkfailures based on different usage scenarios in accordance with variousaspects and embodiments of the subject disclosure in. Repetitivedescription of like elements employed in respective embodiments isomitted for sake of brevity.

At 802, a device comprising a processor (e.g., a UE 102, UE 400, UE 500or the like), monitors (e.g., using the link quality monitoringcomponent 406) a quality of a radio link established between the deviceand a network device (e.g., network node 104) of a wirelesscommunication network based on downlink transmissions received from thenetwork device. At 804, the device determines (e.g., using the linkquality evaluation component 408) whether the quality indicates thedevice and the network device are out of synchronization based on thequality being below a defined quality level, wherein the defined qualitylevel varies based on a CORESET group associated with trafficcommunicated between the device and the network device via the radiolink. In this regard, the defined quality level and the measured qualityof radio link can reflect one or more RLM/RLF procedurerequirement/parameters that are tailored to the CORESET group, includingbut not limited to: the particular characteristics of thehypothetical/reference PDCCH transmissions applied to determine the BLERvalues corresponding to link quality measurements, the particularreference signal characteristics/combinations used to determine the BLERvalues, the specific Qout and Qin values, and the number of consecutiveout-of-sync indications applied to initiate the RLF timer.

At 806, based on a first determination that the quality of the radiolink indicates the device and the network device are out ofsynchronization, the device continues, the monitoring of the quality ofthe radio link for a defined time period (e.g., the RLF timer period202), wherein the defined time period is variable based on the CORSETgroup. At 808, the device further determines, (e.g., using the linkquality evaluation component 408) whether the quality indicates afailure of the radio link based on the quality remaining below thedefined quality profile for the defined time period. In this regard,quality can be considered to remain below the defined threshold qualityif the UE continues to detect out-of-sync indications over the durationof the RLF timer period and/or the UE does not detect a defined numberof consecutive in-sync indications within the RLF timer period to forgodeclaration of a RLF and stop the RLF timer. In addition to the durationof the RLF timer, the measure for determining the out-of syncindications is again tailored to the current CORSET group. Likewise, themeasure for the in-sync indications and the defined number of in-syncindications can be tailored to the current CORESET group.

FIG. 9 illustrates an example method 900 for detecting and correctingradio link failures based on different usage scenarios in accordancewith various aspects and embodiments of the subject disclosure.Repetitive description of like elements employed in respectiveembodiments is omitted for sake of brevity.

At 902, a device comprising a processor (e.g., a UE 102, UE 400, UE 500or the like), deactivates (e.g., using the communication component 402)a radio link established between the device and a network device (e.g.,the network node 104) of a wireless communication network, wherein thedeactivating is based on a determination that the radio link has failedmonitors (e.g., e.g., a determination of RLF by link quality monitoringcomponent 406). For example, the deactivation of the radio link caninvolve the UE turning off its transmitter to avoid interferenceassociated with subsequent performance of the RRC connectionre-establishment procedure. At 904, the device performs the connectionre-establishment procedure (e.g., using the communication component 402and the reconnection component 412) to re-establish the radio link withthe network device based on the deactivating the radio link, wherein theconnection re-establishment procedure varies based on a CORESET groupassociated with traffic communicated between the device and the networkdevice via the radio link. For example, one or more timers or delayrequirements associated with one or RACH events can be applied that arespecifically tailored to the current CORSET group (e.g., the RAR windowand/or the RRC re-establishment period 203). In another example,time/frequency resources used for RACH preamble transmission can beconfigured based on CORESET group. In various implementations, the usagescenario identification component 404 can instruct the communicationcomponent regarding the specific RRC connection re-establishmentparameters to apply during the RRC connection re-establishment procedurebased on the identified CORSET group associated with the traffic and theRLM/RLF procedure information. Further, in some embodiments, theconnection re-establishment procedure can comprise sending a connectionrequest (e.g., the RRC connection request/the L2/L3 message of the RACHprocedure) by the device to the network device comprising informationidentifying a reason for the RLF based on the CORSET group. For example,the reason can be selected from a group comprising: a synchronizationfailure between the device and the network device, and an inability tosuccessfully perform a beam failure recovery process.

The proposed novel RLM/RLF and RRC connection re-establishmentprocedures based on CORESET groups that correspond to different usagescenarios/traffic types and quality of service requirements allows fortrue flexibility in meeting key performance requirements for the varioustypes of traffic envisioned. The proposed configurable RLM/RLFprocedures allow for flexible mechanisms to be implemented resulting inimproved performance when reliability and latency are key performancemetrics. Furthermore differentiating between random access proceduredelay and resource requirements for various usage scenarios, and hencedifferent CORESET groups, results in a more optimized and targetedprocedure towards the corresponding traffic.

FIG. 10 is a schematic block diagram of a computing environment 1000with which the disclosed subject matter can interact. The system 1000comprises one or more remote component(s) 1010. The remote component(s)1010 can be hardware and/or software (e.g., threads, processes,computing devices). In some embodiments, remote component(s) 1010 cancomprise servers, personal servers, wireless telecommunication networkdevices, RAN device(s), etc. As an example, remote component(s) 1010 canbe network node 104, one or more network devices 108, and the like. Thesystem 1000 also comprises one or more local component(s) 1020. Thelocal component(s) 1020 can be hardware and/or software (e.g., threads,processes, computing devices). In some embodiments, local component(s)1020 can comprise, for example, UE 102, UE 400, UE 500 and the like.

One possible communication between a remote component(s) 1010 and alocal component(s) 1020 can be in the form of a data packet adapted tobe transmitted between two or more computer processes. Another possiblecommunication between a remote component(s) 1010 and a localcomponent(s) 1020 can be in the form of circuit-switched data adapted tobe transmitted between two or more computer processes in radio timeslots. The system 1000 comprises a communication framework 1040 that canbe employed to facilitate communications between the remote component(s)1010 and the local component(s) 1020, and can comprise an air interface,e.g., Uu interface of a UMTS network, via an LTE network, etc. Remotecomponent(s) 1010 can be operably connected to one or more remote datastore(s) 1050, such as a hard drive, solid state drive, SIM card, devicememory, etc., that can be employed to store information on the remotecomponent(s) 1010 side of communication framework 1040. Similarly, localcomponent(s) 1020 can be operably connected to one or more local datastore(s) 1030, that can be employed to store information on the localcomponent(s) 1020 side of communication framework 1040.

In order to provide a context for the various aspects of the disclosedsubject matter, FIG. 11, and the following discussion, are intended toprovide a brief, general description of a suitable environment in whichthe various aspects of the disclosed subject matter can be implemented.While the subject matter has been described above in the general contextof computer-executable instructions of a computer program that runs on acomputer and/or computers, those skilled in the art will recognize thatthe disclosed subject matter also can be implemented in combination withother program modules. Generally, program modules comprise routines,programs, components, data structures, etc. that performs particulartasks and/or implement particular abstract data types.

In the subject specification, terms such as “store,” “storage,” “datastore,” data storage,” “database,” and substantially any otherinformation storage component relevant to operation and functionality ofa component, refer to “memory components,” or entities embodied in a“memory” or components comprising the memory. It is noted that thememory components described herein can be either volatile memory ornonvolatile memory, or can comprise both volatile and nonvolatilememory, by way of illustration, and not limitation, volatile memory 1120(see below), non-volatile memory 1122 (see below), disk storage 1124(see below), and memory storage 1146 (see below). Further, nonvolatilememory can be included in read only memory, programmable read onlymemory, electrically programmable read only memory, electricallyerasable read only memory, or flash memory. Volatile memory can compriserandom access memory, which acts as external cache memory. By way ofillustration and not limitation, random access memory is available inmany forms such as synchronous random access memory, dynamic randomaccess memory, synchronous dynamic random access memory, double datarate synchronous dynamic random access memory, enhanced synchronousdynamic random access memory, Synchlink dynamic random access memory,and direct Rambus random access memory. Additionally, the disclosedmemory components of systems or methods herein are intended to comprise,without being limited to comprising, these and any other suitable typesof memory.

Moreover, it is noted that the disclosed subject matter can be practicedwith other computer system configurations, comprising single-processoror multiprocessor computer systems, mini-computing devices, mainframecomputers, as well as personal computers, hand-held computing devices(e.g., personal digital assistant, phone, watch, tablet computers,notebook computers, . . . ), microprocessor-based or programmableconsumer or industrial electronics, and the like. The illustratedaspects can also be practiced in distributed computing environmentswhere tasks are performed by remote processing devices that are linkedthrough a communications network; however, some if not all aspects ofthe subject disclosure can be practiced on stand-alone computers. In adistributed computing environment, program modules can be located inboth local and remote memory storage devices.

FIG. 11 illustrates a block diagram of a computing system 1100 operableto execute the disclosed systems and methods in accordance with anembodiment. Computer 1112, which can be, for example, a UE (e.g., UE 102and 400, 500 and the like), a network node (e.g., network node 104), acore network device (e.g., network device 108), and the like comprises aprocessing unit 1114, a system memory 1116, and a system bus 1118.System bus 1118 couples system components comprising, but not limitedto, system memory 1116 to processing unit 1114. Processing unit 1114 canbe any of various available processors. Dual microprocessors and othermultiprocessor architectures also can be employed as processing unit1114.

System bus 1118 can be any of several types of bus structure(s)comprising a memory bus or a memory controller, a peripheral bus or anexternal bus, and/or a local bus using any variety of available busarchitectures comprising, but not limited to, industrial standardarchitecture, micro-channel architecture, extended industrial standardarchitecture, intelligent drive electronics, video electronics standardsassociation local bus, peripheral component interconnect, card bus,universal serial bus, advanced graphics port, personal computer memorycard international association bus, Firewire (Institute of Electricaland Electronics Engineers 11104), and small computer systems interface.

System memory 1116 can comprise volatile memory 1120 and nonvolatilememory 1122. A basic input/output system, containing routines totransfer information between elements within computer 1112, such asduring start-up, can be stored in nonvolatile memory 1122. By way ofillustration, and not limitation, nonvolatile memory 1122 can compriseread only memory, programmable read only memory, electricallyprogrammable read only memory, electrically erasable read only memory,or flash memory. Volatile memory 1120 comprises read only memory, whichacts as external cache memory. By way of illustration and notlimitation, read only memory is available in many forms such assynchronous random access memory, dynamic read only memory, synchronousdynamic read only memory, double data rate synchronous dynamic read onlymemory, enhanced synchronous dynamic read only memory, Synchlink dynamicread only memory, Rambus direct read only memory, direct Rambus dynamicread only memory, and Rambus dynamic read only memory.

Computer 1112 can also comprise removable/non-removable,volatile/non-volatile computer storage media. FIG. 11 illustrates, forexample, disk storage 1124. Disk storage 1124 comprises, but is notlimited to, devices like a magnetic disk drive, floppy disk drive, tapedrive, flash memory card, or memory stick. In addition, disk storage1124 can comprise storage media separately or in combination with otherstorage media comprising, but not limited to, an optical disk drive suchas a compact disk read only memory device, compact disk recordabledrive, compact disk rewritable drive or a digital versatile disk readonly memory. To facilitate connection of the disk storage devices 1124to system bus 1118, a removable or non-removable interface is typicallyused, such as interface 1126.

Computing devices typically comprise a variety of media, which cancomprise computer-readable storage media or communications media, whichtwo terms are used herein differently from one another as follows.

Computer-readable storage media can be any available storage media thatcan be accessed by the computer and comprises both volatile andnonvolatile media, removable and non-removable media. By way of example,and not limitation, computer-readable storage media can be implementedin connection with any method or technology for storage of informationsuch as computer-readable instructions, program modules, structureddata, or unstructured data. Computer-readable storage media cancomprise, but are not limited to, read only memory, programmable readonly memory, electrically programmable read only memory, electricallyerasable read only memory, flash memory or other memory technology,compact disk read only memory, digital versatile disk or other opticaldisk storage, magnetic cassettes, magnetic tape, magnetic disk storageor other magnetic storage devices, or other tangible media which can beused to store desired information. In this regard, the term “tangible”herein as may be applied to storage, memory or computer-readable media,is to be understood to exclude only propagating intangible signals perse as a modifier and does not relinquish coverage of all standardstorage, memory or computer-readable media that are not only propagatingintangible signals per se. In an aspect, tangible media can comprisenon-transitory media wherein the term “non-transitory” herein as may beapplied to storage, memory or computer-readable media, is to beunderstood to exclude only propagating transitory signals per se as amodifier and does not relinquish coverage of all standard storage,memory or computer-readable media that are not only propagatingtransitory signals per se. Computer-readable storage media can beaccessed by one or more local or remote computing devices, e.g., viaaccess requests, queries or other data retrieval protocols, for avariety of operations with respect to the information stored by themedium. As such, for example, a computer-readable medium can compriseexecutable instructions stored thereon that, in response to execution,cause a system comprising a processor to perform operations, comprisinggenerating an RRC connection release message further comprisingalterative band channel data.

Communications media typically embody computer-readable instructions,data structures, program modules or other structured or unstructureddata in a data signal such as a modulated data signal, e.g., a carrierwave or other transport mechanism, and comprises any informationdelivery or transport media. The term “modulated data signal” or signalsrefers to a signal that has one or more of its characteristics set orchanged in such a manner as to encode information in one or moresignals. By way of example, and not limitation, communication mediacomprise wired media, such as a wired network or direct-wiredconnection, and wireless media such as acoustic, RF, infrared and otherwireless media.

It can be noted that FIG. 11 describes software that acts as anintermediary between users and computer resources described in suitableoperating environment 1100. Such software comprises an operating system1128. Operating system 1128, which can be stored on disk storage 1124,acts to control and allocate resources of computer system 1112. Systemapplications 1130 take advantage of the management of resources byoperating system 1128 through program modules 1132 and program data 1134stored either in system memory 1116 or on disk storage 1124. It is to benoted that the disclosed subject matter can be implemented with variousoperating systems or combinations of operating systems.

A user can enter commands or information into computer 1112 throughinput device(s) 1136. In some embodiments, a user interface can allowentry of user preference information, etc., and can be embodied in atouch sensitive display panel, a mouse/pointer input to a graphical userinterface (GUI), a command line controlled interface, etc., allowing auser to interact with computer 1112. Input devices 1136 comprise, butare not limited to, a pointing device such as a mouse, trackball,stylus, touch pad, keyboard, microphone, joystick, game pad, satellitedish, scanner, TV tuner card, digital camera, digital video camera, webcamera, cell phone, smartphone, tablet computer, etc. These and otherinput devices connect to processing unit 1114 through system bus 1118 byway of interface port(s) 1138. Interface port(s) 1138 comprise, forexample, a serial port, a parallel port, a game port, a universal serialbus, an infrared port, a Bluetooth port, an IP port, or a logical portassociated with a wireless service, etc. Output device(s) 1140 use someof the same type of ports as input device(s) 1136.

Thus, for example, a universal serial busport can be used to provideinput to computer 1112 and to output information from computer 1112 toan output device 1140. Output adapter 1142 is provided to illustratethat there are some output devices 1140 like monitors, speakers, andprinters, among other output devices 1140, which use special adapters.Output adapters 1142 comprise, by way of illustration and notlimitation, video and sound cards that provide means of connectionbetween output device 1140 and system bus 1118. It should be noted thatother devices and/or systems of devices provide both input and outputcapabilities such as remote computer(s) 1144.

Computer 1112 can operate in a networked environment using logicalconnections to one or more remote computers, such as remote computer(s)1144. Remote computer(s) 1144 can be a personal computer, a server, arouter, a network PC, cloud storage, a cloud service, code executing ina cloud-computing environment, a workstation, a microprocessor basedappliance, a peer device, or other common network node and the like, andtypically comprises many or all of the elements described relative tocomputer 1112. A cloud computing environment, the cloud, or othersimilar terms can refer to computing that can share processing resourcesand data to one or more computer and/or other device(s) on an as neededbasis to enable access to a shared pool of configurable computingresources that can be provisioned and released readily. Cloud computingand storage solutions can storing and/or processing data in third-partydata centers which can leverage an economy of scale and can viewaccessing computing resources via a cloud service in a manner similar toa subscribing to an electric utility to access electrical energy, atelephone utility to access telephonic services, etc.

For purposes of brevity, only a memory storage device 1146 isillustrated with remote computer(s) 1144. Remote computer(s) 1144 islogically connected to computer 1112 through a network interface 1148and then physically connected by way of communication connection 1150.Network interface 1148 encompasses wire and/or wireless communicationnetworks such as local area networks and wide area networks. Local areanetwork technologies comprise fiber distributed data interface, copperdistributed data interface, Ethernet, Token Ring and the like. Wide areanetwork technologies comprise, but are not limited to, point-to-pointlinks, circuit-switching networks like integrated services digitalnetworks and variations thereon, packet switching networks, and digitalsubscriber lines. As noted below, wireless technologies may be used inaddition to or in place of the foregoing.

Communication connection(s) 1150 refer(s) to hardware/software employedto connect network interface 1148 to bus 1118. While communicationconnection 1150 is shown for illustrative clarity inside computer 1112,it can also be external to computer 1112. The hardware/software forconnection to network interface 1148 can comprise, for example, internaland external technologies such as modems, comprising regular telephonegrade modems, cable modems and digital subscriber line modems,integrated services digital network adapters, and Ethernet cards.

The above description of illustrated embodiments of the subjectdisclosure, comprising what is described in the Abstract, is notintended to be exhaustive or to limit the disclosed embodiments to theprecise forms disclosed. While specific embodiments and examples aredescribed herein for illustrative purposes, various modifications arepossible that are considered within the scope of such embodiments andexamples, as those skilled in the relevant art can recognize.

In this regard, while the disclosed subject matter has been described inconnection with various embodiments and corresponding Figures, whereapplicable, it is to be understood that other similar embodiments can beused or modifications and additions can be made to the describedembodiments for performing the same, similar, alternative, or substitutefunction of the disclosed subject matter without deviating therefrom.Therefore, the disclosed subject matter should not be limited to anysingle embodiment described herein, but rather should be construed inbreadth and scope in accordance with the appended claims below.

As it employed in the subject specification, the term “processor” canrefer to substantially any computing processing unit or devicecomprising, but not limited to comprising, single-core processors;single-processors with software multithread execution capability;multi-core processors; multi-core processors with software multithreadexecution capability; multi-core processors with hardware multithreadtechnology; parallel platforms; and parallel platforms with distributedshared memory. Additionally, a processor can refer to an integratedcircuit, an application specific integrated circuit, a digital signalprocessor, a field programmable gate array, a programmable logiccontroller, a complex programmable logic device, a discrete gate ortransistor logic, discrete hardware components, or any combinationthereof designed to perform the functions described herein. Processorscan exploit nano-scale architectures such as, but not limited to,molecular and quantum-dot based transistors, switches and gates, inorder to optimize space usage or enhance performance of user equipment.A processor may also be implemented as a combination of computingprocessing units.

As used in this application, the terms “component,” “system,”“platform,” “layer,” “selector,” “interface,” and the like are intendedto refer to a computer-related entity or an entity related to anoperational apparatus with one or more specific functionalities, whereinthe entity can be either hardware, a combination of hardware andsoftware, software, or software in execution. As an example, a componentmay be, but is not limited to being, a process running on a processor, aprocessor, an object, an executable, a thread of execution, a program,and/or a computer. By way of illustration and not limitation, both anapplication running on a server and the server can be a component. Oneor more components may reside within a process and/or thread ofexecution and a component may be localized on one computer and/ordistributed between two or more computers. In addition, these componentscan execute from various computer readable media having various datastructures stored thereon. The components may communicate via localand/or remote processes such as in accordance with a signal having oneor more data packets (e.g., data from one component interacting withanother component in a local system, distributed system, and/or across anetwork such as the Internet with other systems via the signal). Asanother example, a component can be an apparatus with specificfunctionality provided by mechanical parts operated by electric orelectronic circuitry, which is operated by a software or firmwareapplication executed by a processor, wherein the processor can beinternal or external to the apparatus and executes at least a part ofthe software or firmware application. As yet another example, acomponent can be an apparatus that provides specific functionalitythrough electronic components without mechanical parts, the electroniccomponents can comprise a processor therein to execute software orfirmware that confers at least in part the functionality of theelectronic components.

In addition, the term “or” is intended to mean an inclusive “or” ratherthan an exclusive “or.” That is, unless specified otherwise, or clearfrom context, “X employs A or B” is intended to mean any of the naturalinclusive permutations. That is, if X employs A; X employs B; or Xemploys both A and B, then “X employs A or B” is satisfied under any ofthe foregoing instances. Moreover, articles “a” and “an” as used in thesubject specification and annexed drawings should generally be construedto mean “one or more” unless specified otherwise or clear from contextto be directed to a singular form.

Further, the term “include” is intended to be employed as an open orinclusive term, rather than a closed or exclusive term. The term“include” can be substituted with the term “comprising” and is to betreated with similar scope, unless otherwise explicitly used otherwise.As an example, “a basket of fruit including an apple” is to be treatedwith the same breadth of scope as, “a basket of fruit comprising anapple.”

Moreover, terms like “user equipment (UE),” “mobile station,” “mobile,”subscriber station,” “subscriber equipment,” “access terminal,”“terminal,” “handset,” and similar terminology, refer to a wirelessdevice utilized by a subscriber or user of a wireless communicationservice to receive or convey data, control, voice, video, sound, gaming,or substantially any data-stream or signaling-stream. The foregoingterms are utilized interchangeably in the subject specification andrelated drawings. Likewise, the terms “access point,” “base station,”“Node B,” “evolved Node B,” “eNodeB,” “home Node B,” “home accesspoint,” and the like, are utilized interchangeably in the subjectapplication, and refer to a wireless network component or appliance thatserves and receives data, control, voice, video, sound, gaming, orsubstantially any data-stream or signaling-stream to and from a set ofsubscriber stations or provider enabled devices. Data and signalingstreams can comprise packetized or frame-based flows.

Additionally, the terms “core-network”, “core”, “core carrier network”,“carrier-side”, or similar terms can refer to components of atelecommunications network that typically provides some or all ofaggregation, authentication, call control and switching, charging,service invocation, or gateways. Aggregation can refer to the highestlevel of aggregation in a service provider network wherein the nextlevel in the hierarchy under the core nodes is the distribution networksand then the edge networks. UEs do not normally connect directly to thecore networks of a large service provider but can be routed to the coreby way of a switch or radio access network. Authentication can refer todeterminations regarding whether the user requesting a service from thetelecom network is authorized to do so within this network or not. Callcontrol and switching can refer determinations related to the futurecourse of a call stream across carrier equipment based on the callsignal processing. Charging can be related to the collation andprocessing of charging data generated by various network nodes. Twocommon types of charging mechanisms found in present day networks can beprepaid charging and postpaid charging. Service invocation can occurbased on some explicit action (e.g. call transfer) or implicitly (e.g.,call waiting). It is to be noted that service “execution” may or may notbe a core network functionality as third party network/nodes may takepart in actual service execution. A gateway can be present in the corenetwork to access other networks. Gateway functionality can be dependenton the type of the interface with another network.

Furthermore, the terms “user,” “subscriber,” “customer,” “consumer,”“prosumer,” “agent,” and the like are employed interchangeablythroughout the subject specification, unless context warrants particulardistinction(s) among the terms. It should be appreciated that such termscan refer to human entities or automated components (e.g., supportedthrough artificial intelligence, as through a capacity to makeinferences based on complex mathematical formalisms), that can providesimulated vision, sound recognition and so forth.

Aspects, features, or advantages of the subject matter can be exploitedin substantially any, or any, wired, broadcast, wirelesstelecommunication, radio technology or network, or combinations thereof.Non-limiting examples of such technologies or networks comprisebroadcast technologies (e.g., sub-Hertz, extremely low frequency, verylow frequency, low frequency, medium frequency, high frequency, veryhigh frequency, ultra-high frequency, super-high frequency, terahertzbroadcasts, etc.); Ethernet; X.25; powerline-type networking, e.g.,Powerline audio video Ethernet, etc.; femtocell technology; Wi-Fi;worldwide interoperability for microwave access; enhanced general packetradio service; third generation partnership project, long termevolution; third generation partnership project universal mobiletelecommunications system; third generation partnership project 2, ultramobile broadband; high speed packet access; high speed downlink packetaccess; high speed uplink packet access; enhanced data rates for globalsystem for mobile communication evolution radio access network;universal mobile telecommunications system terrestrial radio accessnetwork; or long term evolution advanced.

The term “infer” or “inference” can generally refer to the process ofreasoning about, or inferring states of, the system, environment, user,and/or intent from a set of observations as captured via events and/ordata. Captured data and events can include user data, device data,environment data, data from sensors, sensor data, application data,implicit data, explicit data, etc. Inference, for example, can beemployed to identify a specific context or action, or can generate aprobability distribution over states of interest based on aconsideration of data and events. Inference can also refer to techniquesemployed for composing higher-level events from a set of events and/ordata. Such inference results in the construction of new events oractions from a set of observed events and/or stored event data, whetherthe events, in some instances, can be correlated in close temporalproximity, and whether the events and data come from one or severalevent and data sources. Various classification schemes and/or systems(e.g., support vector machines, neural networks, expert systems,Bayesian belief networks, fuzzy logic, and data fusion engines) can beemployed in connection with performing automatic and/or inferred actionin connection with the disclosed subject matter.

What has been described above includes examples of systems and methodsillustrative of the disclosed subject matter. It is, of course, notpossible to describe every combination of components or methods herein.One of ordinary skill in the art may recognize that many furthercombinations and permutations of the claimed subject matter arepossible. Furthermore, to the extent that the terms “includes,” “has,”“possesses,” and the like are used in the detailed description, claims,appendices and drawings such terms are intended to be inclusive in amanner similar to the term “comprising” as “comprising” is interpretedwhen employed as a transitional word in a claim.

What is claimed is:
 1. A device, comprising: a processor, and a memorythat stores executable instructions that, when executed by theprocessor, facilitate performance of operations, comprising:deactivating a radio link with network equipment based on adetermination that a radio link failure has occurred; determining timeand frequency resources for a preamble transmission of a procedure forre-establishing the radio link with the network equipment based on acontrol channel resource set group applicable to the device, wherein thetime and frequency resources for the preamble transmission vary fordifferent control channel resource set groups; and performing theprocedure using the time and frequency resources for the preambletransmission.
 2. The device of claim 1, wherein the operations furthercomprise: prior to the deactivating, employing the control channelresource set group to decode downlink control information received fromthe network equipment.
 3. The device of claim 1, wherein the networkequipment configures the different control channel resource set groupsfor different types of traffic.
 4. The device of claim 3, wherein thedifferent types of traffic are selected from a group of types oftraffic, the group comprising: a first type associated with enhancedmobile broadband traffic, a second type associated with ultra reliableand low latency traffic, and a third type associated with massivemachine type communication traffic.
 5. The device of claim 1, whereinthe procedure varies based on the control channel resource set group. 6.The device of claim 5, wherein the procedure varies with respect to atimer associated with performance of the procedure.
 7. The device ofclaim 5, wherein the procedure varies with respect to a configurationparameter associated with resources used for the procedure.
 8. Thedevice of claim 1, wherein performing the procedure comprises sendinginformation to the network equipment indicating a reason for thedetermination that the radio link failure occurred.
 9. The device ofclaim 8, wherein the reason varies based on the control channel resourceset group.
 10. The device of claim 8, wherein the procedure comprises arandom access procedure, and wherein sending the information comprisessending the information in association with transmission of message 3 inaccordance with the random access procedure.
 11. A method, comprising:deactivating, by a device comprising a processor, a radio link withnetwork equipment based on a determination that a radio link failure hasoccurred; determining, by the device, time and frequency resources for apreamble transmission of a procedure for re-establishing the radio linkwith the network equipment based on a control channel resource set groupapplicable to the device, wherein the time and frequency resources forthe preamble transmission vary for different control channel resourceset groups; and sending, by the device, the preamble transmission to thenetwork equipment using the time and frequency resources in associationwith performance of the procedure.
 12. The method of claim 11, furthercomprising: prior to the deactivating, employing, by the device, thecontrol channel resource set group to decode downlink controlinformation received from the network equipment.
 13. The method of claim11, wherein the network equipment configures the different controlchannel resource set groups for different types of traffic.
 14. Themethod of claim 13, wherein different types of traffic are selected fromthe group consisting of: an enhanced mobile broadband traffic type, anultra reliable and low latency traffic type, and a massive machine typecommunication traffic type.
 15. The method of claim 11, wherein theprocedure varies based on the control channel resource set group. 16.The method of claim 11, further comprising: sending, by the device,information to the network equipment indicating a reason for thedetermination that the radio link failure occurred.
 17. The method ofclaim 16, wherein the reason varies based on the control channelresource set group.
 18. The method of claim 16, wherein the procedurecomprises a random access procedure, and wherein sending the informationcomprises sending the information in association with transmission ofmessage 3 in accordance with the random access procedure.
 19. Anon-transitory machine-readable storage medium, comprising executableinstructions that, when executed by a processor of a device, facilitateperformance of operations, comprising: disassembling a radio connectionwith network equipment based on a determination that a radio linkfailure event has occurred; determining time and frequency resources fora preamble transmission of a procedure for re-establishing the radioconnection with the network equipment based on a control channelresource set group applicable to the device, wherein the time andfrequency resources for the preamble transmission vary for differentcontrol channel resource set groups; and sending the preambletransmission to the network equipment using the time and frequencyresources in association with performance of the procedure.
 20. Thenon-transitory machine-readable storage medium of claim 19, wherein theoperations further comprise: sending information to the networkequipment indicating a reason for the determination that the radio linkfailure event occurred in association with transmission of message 3 inaccordance with the procedure, and wherein the reason varies based onthe control channel resource set group.